今天的故事

開始做 PawPal 以前，我其實沒有真正建立資料庫的經驗。

課程沒有教到怎麼建立資料庫，所以第一次真的碰到這一塊時，對我來說幾乎整個都是陌生的。

以前看到網站上的資料，我比較容易把注意力放在畫面上。

例如：

寵物名字

生日

體重

照片

備註

我知道這些東西最後會顯示在畫面上。

但當我真的要開始做的時候，才第一次遇到另一個問題：

這些資料到底要存在哪裡？

而且不只是「存進去」而已。

還要開始想：

資料表要有哪些欄位？

欄位要叫什麼？

要存文字還是數字？

哪些資料真的需要保存？

這些對當時的我來說，幾乎都是第一次碰。

所以我不是先學會怎麼設計資料庫，才開始做 PawPal。

反而是 PawPal 做到需要資料庫之後，我才開始一步一步摸索。

我的第一步，是先想自己需要什麼

剛開始時，我的方式其實很直接。

先看目前要做的功能，再想：

這個功能需要保存哪些資料？

例如做寵物資料時，我會先把自己覺得需要的欄位列出來：

名字

生日

年齡

體重

照片

備註

……

那時候我比較在意的是：

畫面需要這些資料，那資料庫是不是就要有這些欄位？

所以通常是先自己規劃一版。

接著才拿著這些欄位，一個一個跟 AI 討論。

我會問：

這個欄位應該用什麼型態？

這樣存合理嗎？

SQL 要怎麼寫？

這個欄位是不是需要？

如果 AI 提出另外一種做法，我也不是直接全部照著用。

我會先看懂它大概在說什麼。

如果跟我想做的功能不一樣，就再繼續問：

可是我現在的需求是這樣，還適合這樣設計嗎？

然後再慢慢調整。

所以整個過程比較像：

先整理自己的需求
↓
想好大概要存哪些資料
↓
跟 AI 一個一個討論
↓
遇到不懂的就問
↓
先理解大概意思
↓
再決定要不要採用
↓
不符合需求就繼續調整

我就是這樣一步一步，把自己當時要處理的資料表慢慢整理出來。

一開始，我真的比較在意「現在需要什麼」

因為整個資料庫對我來說都很陌生，所以一開始我沒有辦法想得很遠。

當下比較像：

現在這個功能需要哪些資料？

需要，就先加進去。

這個方式其實很直覺。

因為當時光是弄懂：

資料表怎麼建立

欄位怎麼寫

資料型態怎麼選

資料怎麼成功存進去

就已經有很多東西要理解。

更不用說一開始就去思考：

這個欄位半年後還適不適合？

其他功能以後會不會也用到？

這張表之後會不會需要和其他資料建立關係？

這些事情，我當時其實沒有想得那麼細。

所以最開始的做法就是：

先把眼前功能需要的資料整理好
↓
先讓資料可以存
↓
先讓功能可以繼續做

但 PawPal 的功能越做越多之後，我才慢慢發現：

前面資料怎麼整理，後面的功能真的可能會受到影響。

有些資料表後來需要回頭修改。

新的功能出現後，也開始需要讓原本不同的資料彼此產生關係。

這時候我才開始發現：

資料庫不是每出現一個新需求，就一直往資料表裡加欄位這麼單純。

重新翻 Git，我看到自己很早就回頭改過 pets

如果現在要我說：

當時到底是哪一個功能，第一次讓我發現資料表需要重新調整？

老實說，我現在已經沒有很明確的記憶。

所以寫這篇之前，我重新翻了一次 PawPal 的 Git 紀錄。

結果看到一個很直接的例子。

我建立 pets 資料表後，沒過多久，就又有一次欄位整理。

從 Git 紀錄來看，初版的 pets 曾經包含：

birthday

age

weight

note

photo_url

後來又有一筆欄位對齊的修改。

如果用「簡化概念」來看：

原本

age

note

photo_url

↓ 回頭整理

移除 age

notes

avatar_url

對應的 seed 資料也一起跟著調整。

而這兩次修改，都是我當時直接提交的。

現在回頭看，這段 Git 紀錄其實很直接：

先建立
↓
沒多久
↓
又回頭整理

但我現在已經不記得當時到底是哪一個精確需求，讓我決定移除 age，或是修改另外兩個欄位名稱。

Git 可以證明「有改」。

卻不能證明我當時腦中到底在想什麼。

所以這篇我也不想為了讓故事聽起來更完整，就自己補一個：

因為某個功能，所以我才這樣改。

現在能確定的事情其實已經很夠了：

資料表建立之後，我確實很快就又回頭整理過它。

原來資料表不是建完就結束

如果只是看這幾個欄位的變化，好像只是很普通的修改。

但現在回頭看，我覺得它剛好可以代表我當時學資料庫的狀態。

一開始我比較容易想成：

需要資料
↓
建立欄位
↓
可以存
↓
完成

但真的做專案後，才發現比較像：

先建立
↓
開始使用
↓
功能繼續往下做
↓
發現有些地方需要調整
↓
再回頭整理

而且後面不只是在同一張表裡改欄位。

當功能越來越多時，我才開始看到不同資料表之間也會慢慢出現關聯。

例如概念上可能會變成：

一個會員
↓
有自己的寵物

不同功能
↓
又和這些資料產生新的關係

我當時沒有辦法一開始就把這些關係全部規劃好。

但做到後面，我開始知道，原本建立的資料，之後還可能會被其他功能用到。

這也是為什麼我後來開始覺得，建立欄位以前至少要先多想一下。

現在我至少會先多問自己一個問題

以前看到需求，我比較容易想：

需要這個資料，那就加一個欄位。

現在我還是沒有辦法一開始就把所有事情都預測好。

但至少會先多問自己：

這個欄位之後會不會影響其他功能？

我沒有想得非常細。

也不是已經會完整規劃什麼 Database Architecture。

只是開始知道：

需求出現
↓
不要馬上加欄位
↓
先想一下真的需要存什麼
↓
再決定怎麼處理

對現在的我來說，這個「多想一下」其實就是最大的差別。

AI 幫我補的是我當時不知道的地方

因為課程沒有教到建立資料庫，所以 AI 在這段過程中確實幫了我很多。

很多時候，我不是不知道自己想做什麼。

而是不知道：

我想做的這件事，在資料庫裡到底應該怎麼表示？

所以我會先把需求講清楚，再慢慢問。

例如：

我想存這些資料
↓
這些欄位怎麼安排？
↓
某個型態是什麼意思？
↓
為什麼建議這樣寫？

AI 提出建議後，我會先看懂大概的意思，再決定要不要採用。

如果不符合我的需求，就繼續調整。

所以 AI 對我來說不是：

幫我把資料庫全部設計好。

而比較像：

我先把自己要解決的問題整理出來，再利用 AI 補上我不知道的知識。

這次至少讓我知道，遇到不懂的東西時，可以先把自己真正想做的事情整理清楚，再去問問題。

這段經驗讓我開始多想一步

回頭看第一次碰資料庫的過程，我覺得自己主要學到三件事。

第一個是：

建立資料表以前，要先想自己到底需要保存哪些資料。

第二個是：

不懂的時候，可以先把自己的需求整理清楚，再一步一步找答案。

第三個則是：

欄位不是加完就結束，專案往後發展後，原本的資料表也可能需要重新整理。

以前我比較容易把資料庫想成：

把資料放進去的地方

現在則開始知道，今天怎麼存這些資料，之後的功能可能還會再遇到。

標題裡說的「痛苦」，對我來說更像是：

做到後面，才發現前面沒有先想到的事情，後來就會變成需要重新整理的地方。

而這也讓我知道，下次遇到類似需求時，可以先多想一步。

我現在還不敢說自己會設計資料庫

做到 PawPal 後，我不會說自己已經很會設計資料庫。

其實還有很多東西是我不知道的。

但跟第一次碰資料庫相比，我現在至少知道：

建立資料表以前，要先想清楚自己到底需要存什麼。

資料庫對我來說還有很多要學。

但這段經驗也讓我開始知道：

先把自己的需求整理清楚，再一步一步找答案，比直接照著做更重要。

我不一定能一開始就把資料庫設計得很完整。

但至少現在，我知道不能只是看到需求，就馬上加一個欄位。

先想清楚自己真正需要的是什麼，再開始動手。

對我來說，這就是這次資料庫經驗留下來最大的改變。

下一篇預告

一路從前端畫面、API、資料庫，到後來的測試、除錯與部署，PawPal 也慢慢從一個課程專案變成真的可以使用的網站。

回頭看這整段過程，我學到的其實不只是某一個技術。

更多的是：

一個專案到底怎麼從需求，一步一步走到真正上線？

下一篇：

Day 28｜從開發到上線，我學到的專案流程